Upon being powered or reset, an embedded microcontroller must select a boot device containing a boot image from which the embedded system will run. The microcontroller may support the use of more than one boot device. Multi-booting refers to the microcontroller selecting between multiple available boot devices. In order to support multi-booting, a mechanism is required that allows the microcontroller to select the desired boot device from the set of available boot devices.
Systems typically utilize a default boot vector to identify the boot device containing the boot image that is to be loaded. A default boot vector, which is sometimes referred to as a reset vector, is a designated address space that identifies the location of the boot device from which the system is presently configured to run. Upon a reboot or reset, the CPU accesses the boot vector and is directed to the location of a boot device containing a boot image, which is then loaded. Each boot image will typically include application code for operation of the embedded system and boot loader code for loading the application code. The boot loader initializes the system and loads the application code for execution by the system. In a single boot system, the sole boot image is identified by the boot vector. However, in a multi-boot system, the problem arises as to how to adapt this boot vector mechanism for selecting between multiple available boot devices.
One solution for supporting multi-booting is to change the boot vector that is utilized. This can be accomplished by inserting a jump instruction to be executed in conjunction with a reset instruction. The jump instruction directs the system to the location of a selected boot device. Another possibility is to redefine the location of the boot vector prior to the issuance of a reset command such that, upon reset, the system loads the boot image specified by this redefined boot vector. Another possibility is to circumvent the boot vector by placing the boot image at a fixed address and programming the system to boot directly from this address.
These conventional approaches require making significant changes to the system's software each time a different boot device is selected. For instance, if the location of the boot vector is changed, boot images must be recompiled in order to utilize the new boot vector. As changes to the boot images are made, the user must ensure that updated boot images are configured according to the remapped boot vector. With each change to the location of the boot vector, the user must propagate these changes to all relevant boot images. If the boot vector is circumvented entirely, not only must each boot image be recompiled to point to the address location of the boot code to be used, the device logic itself must be altered to circumvent the default boot vector and, as before, each boot image would have to be recompiled in order to reset to this new boot code location. It would be desirable to have a configurable multi-booting solution that does not require recompiling boot images each time a change to the selected boot device is made. It would be further desirable to enable the multi-booting selections to be made via a simple hardware configuration.